During token streaming, every tree update caused multiple O(n) tree
traversals: once inside the View's _onTreeUpdate(), then again for
each React hook subscriber calling view.flattenNodes(). With rapid
streaming tokens this multiplied into a significant performance cost.

The View now caches the flattenNodes() result in a _cachedNodes field.
The public flattenNodes() returns this cache in O(1). A new private
_computeFlatNodes() method performs the actual tree walk and is called
only when the visible output may have changed: tree structural changes,
branch selection changes, fork auto-selection, and history page reveal.

The original design avoided caching ("no cache invalidation complexity,
at the cost of repeated traversals") because the result depends on
branch selection state. Caching is safe here because every mutation
path that can change the visible output refreshes the cache
synchronously before emitting events to consumers - JS single-threading
eliminates async staleness risks.

During token streaming, every tree update triggered a full O(n) tree
walk even though the tree structure hadn't changed - only a single
message's content was updated. With conversations of hundreds of
messages and tokens arriving at high frequency, this became the
dominant cost on the hot path.

The Tree now exposes a structuralVersion counter (on TreeInternal)
that increments on insert, delete, and serial promotion - but not
on content-only upsert of an existing node. The View compares this
counter against its last-seen version: when unchanged, it takes a
fast path that compares cached message references against the
snapshot in O(visible_count) instead of re-walking the tree.

A monotonic counter was chosen over alternatives (tagged events,
dirty sets, boolean flags) because it requires no public API change,
is multi-View safe (each View tracks its own last-seen version),
and cannot produce false negatives.